home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 411 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  7.4 KB

  1. Path: chronicle.mti.sgi.com!austern
  2. From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Portability. Modules. WAS: RE: Are all Windows programs ill-formed?
  5. Date: 20 Feb 1996 10:56:30 PST
  6. Organization: GABI Software, Sarl.
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <KANZE.96Feb20112203@slsvewt.lts.sel.alcatel.de>
  9. References: <UPMAIL04.199602192354280583@msn.com>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 20 Feb 1996 10:22:03 GMT
  12. In-Reply-To: "Eugene Lazutkin"'s message of 20 Feb 96 07:15:52 GMT
  13. Apparently-To: std-c++@ncar.ucar.edu
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBVAwUBMSoZaEy4NqrwXLNJAQHwXQH8D3tdSLEn2dG6HcMayOcHKlXcBVR0+Xzm
  16.     0yqKrmHA6OQwSFuMK7vk/PNu4DpWVsaCoROz4gAuCH9pX/j53xCagg==
  17.     =+v5v
  18. Originator: austern@isolde.mti.sgi.com
  19.  
  20. In article <UPMAIL04.199602192354280583@msn.com> "Eugene Lazutkin"
  21. <INT@msn.com> writes:
  22.  
  23. |> On     Tuesday, February 13, 1996 7:48 AM,     
  24. |>     James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
  25. |> > In article <01BAF61B.3131B100@dino.int.com> Eugene Lazutkin
  26. |> > <eugene@int.com> writes:
  27.  
  28. |> > The oldest one, rarely used except for the simplest cases today, is to
  29. |> > design the list such that the initial initialization to 0 is adequate,
  30. |> > and give it a special no-op constructor.  Thus, for example, my
  31. |> > command line parser class maintains a list of options (staticly
  32. |> > declared objects); a NULL pointer signifies an empty list, and the
  33. |> > constructor does nothing.  Thus, it doesn't matter if the options are
  34. |> > constructed (and register themselves) before the list.
  35.  
  36. |> It doesn't help to create a simple double-linked ring.  Not all 
  37. |> containers can be built on a single-linked list or a tree structure.
  38. |> E.g., any member of a double linked ring can exclude itself from the 
  39. |> list automatically by its destructor at any time.  You can't do it
  40. |> with single-linked list or with double-linked list (not ring).
  41.  
  42. I've used it for double-linked lists:-).  It does mean 1) that the
  43. list itself is special, and 2) a little bit more code to check the
  44. special case (linked to head/tail).  In the case of 1, this is
  45. generally the case anyway.  For 2, in the cases I've used it,
  46. performance hasn't been a problem.
  47.  
  48. More generally, most of the classes I have that use this are
  49. associative arrays.  The actual array is dynamically allocated (on the
  50. heap), and the only static data is a pointer.  The access routines
  51. check for NULL, and create the array as needed.
  52.  
  53. |> BTW, who frees the allocated memory?  When?  How can I specify the 
  54. |> order of destruction?  ObjectSpace's STL has problems with that.
  55. |> The program using this STL will leak.  They can't eleminate this 
  56. |> problem.  OK, they have a work around.  But it is very inefficient:
  57. |> they use per-object allocators instead of per-class.
  58.  
  59. Order of destruction is undefined.  In general, IMHO, destructors
  60. shouldn't be doing much, so that order of destruction is not a
  61. significant problem.
  62.  
  63. In most cases of static maps, I simply let the memory leak.  Since I
  64. couldn't free it before the static destructors run anyway, there's
  65. really no point; once the process finishes, the OS recovers it anyway.
  66. (I know that this isn't particularly elegant, but solving real
  67. problems has had priority until now.)
  68.  
  69. A potential solution would have the users of the class enrol/deenrol.
  70. When the last user deenrols, clean up.
  71.  
  72. |> > The more frequent solution today is to have a function returning a
  73. |> > reference to a local static object.  The object will be constructed
  74. |> > the first time the function is called.  The enrolment functions in the
  75. |> > Item's call the function to get the actual list object.
  76.  
  77. |> Does this static object have any constructors?  Or its components?
  78. |> Is it based on some class without constructors?  If not, who will
  79. |> be initialize it?  And how?  Who will deinitialize it?  A lot of
  80. |> problems.
  81.  
  82. Of course, it has constructors.  And destructors.  The constructors
  83. are called the first time the function is called.  Note that this is
  84. the only solution (that I know of, at least) that is fully conforming,
  85. and works even if the implementation does not initialize everything
  86. before main.
  87.  
  88. There may still be problems with order of destruction.  According to
  89. the current draft (Jan. 96), all static objects (including those with
  90. block scope) must be destructed in the reverse order of their
  91. construction, so there is at least one guarantee, although probably
  92. not the one you need, at least presuming that order of construction
  93. refers to the order the constructors were entered, and not the order
  94. they were left.
  95.  
  96. Note that most compilers do not yet implement this order of
  97. destruction.  If I remember right, for example, the Sun compiler
  98. (4.0.1) will destruct all file (namespace) scope static objects first,
  99. and then block scope statics.
  100.  
  101. |> Of course, both these solutions work just fine in certain specific 
  102. |> cases.  But it is not a generic answer.  It is a trick.
  103.  
  104. I'll accept this for the first solution.  I only use it in special
  105. cases, and in modern code, practically not at all.  The second
  106. solution is not a trick, however; it is the standard generic answer,
  107. which works in all cases, and ensures destruction.  It may lead to
  108. problems in the order of destruction, but no more than any other
  109. solution.  The best solution here is to not allow destructors to
  110. access *other* static objects.
  111.  
  112. |> > I often encapsulate the above solution in a SharedList interface
  113. |> > class.  All instances of the SharedList actually refer to the same
  114. |> > list object.  The SharedList only contains a pointer to the actual
  115. |> > list object, and forwards all requests to it.  The pointer is
  116. |> > initialized by calling the function above in the constructor.
  117. |> > 
  118. |> > |> Alternative way: include all items into the container manually and
  119. |> > |> don't forget to do this initialization every time when you use this
  120. |> > |> container in your program.
  121. |> > 
  122. |> > This is extremely error prone (as you also point out).  If you are
  123. |> > willing to accept that all of the objects are known in the same
  124. |> > compilation unit, you might as well define them there, and let the
  125. |> > guaranteed order of construction within the compilation unit do the
  126. |> > trick.
  127.  
  128. |> This is C++, not Pascal.  We have separate units.  I think it is too
  129. |> strong requirement to put some logically different items together.
  130. |> I think it is too error-prone.
  131.  
  132. I basically agree, although if the objects aren't related in any way,
  133. then the order of construction between them shouldn't matter:-).  In
  134. fact, of course, I use the registry idiom in almost all cases where I
  135. have something to parse, including the command line options.  I find
  136. it nice that the option is declared near its point of use, and that no
  137. other code (including main) knows about it.  I also find it nice that
  138. I can add a command to a parser without changing a single line of
  139. existing code.
  140. -- 
  141. James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
  142. GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
  143. Conseils, itudes et rialisations en logiciel orienti objet --
  144.                 -- A la recherche d'une activiti dans une region francophone
  145. ---
  146. [ To submit articles: Try just posting with your newsreader.  If that fails,
  147.                       use mailto:std-c++@ncar.ucar.edu
  148.   FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  149.   Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  150.   Comments? mailto:std.c++-request@ncar.ucar.edu 
  151. ]
  152.